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1. INTRODUCTION 


This document describes a development plan for the NASA Avionics Systems 
Division (ASD) Avionics Test Bed (ATB) to be located in building 16 of the 
Johnson Space Center (JSC). The ATB will be a ground based flight avionics 
systems development facility for testing and evaluation of advance technology 
and new concepts. The ATB is designed to facilitate early investigation of 
Orbiter attached flex body experiments, the Space Operations Center (SOC) 
avionics systems, adaptive control systems for Large Space Structures (LSS) 
and a pallet mounted microprocessor flight control system to support 
Orbiter/LSS flight experiments. The ATB will also support evaluation of 
concepts such as Orbiter enhancements and the all electric aircraft avionics 
control systems. 

1.1 BACKGROUND 

Avionics for coming flight programs will employ sophisticated sensor and 
effector systems with integral microprocessors, linked by distributed data 
networks. Redundancy will be employed to enhance reliability. Adaptive 
control systems will provide damping and stability for large lightweight 
flexible structures. Ground-based facilities must measure up to the needs of 
these programs for development and early demonstration of concepts and tech- 
nologies. As programs mature, these facilities must support the orderly 
development with engineering data, design trade-offs, and system-level inte- 
gration studies. 

In the past NAS/* .v. has not established a dedicated integrated avionics 
development facility to provide early evaluations of new concepts prior to the 
release of design requirements for bids. Presently there are independent 
component and subsystem level evaluations conducted in NASA laboratories. 
System level evaluations have been conducted by integration contractors at 
their facilities. Many new concepts will require sufficient empirical 
information for NASA decisions on state-of-the-art technologies. It is the 
goal of the ATB to fill these needs. 
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1.2 PURPOSE 

The purpose of the ATB is to provide a versatile facility to test and evaluate 
new flight avionics technology and concepts from their inception through the 
design and testing of prototype hardware. Two near term expected major users 
of the ATB will be the Space Operations Center (SOC) program and the Orbiter 
with attached LSS. The ATB will be a major contributor in the partitioning 
and configuration of the SOC avionics system in preparation of design require- 
ments. The ATB will be capable of large scale adaptation to, as yet unknown, 
SOC avionics concepts and technologies. For LSS the ATB will .upport design, 
development and verification of a pallet mounted control system which would 
compliment the Orbiter flight control subsystem for LSS attached unique 
requirements. The ATB is projected to provide the following benefits for 
NASA: 

• Produces confidence very early in the concept development. 

• Provides hands-on experience in new technology issues Tor personnel who are 
responsible for development of design requirements. 

• Facilitates a systems level evaluation of subsystem functional elements and 
concepts long before commitment to final design and hardware fabrication. 

• Provides a reconfigurable/flexible facility for early integration of design 
concepts with previously developed new hardware. 

• Accommodates relatively fast test and evaluation of new technologies and 
concepts in a development atmosphere. 

1.3 DOCUMENT OBJECTIVE 

The objective of the ATB Development Plan is to define a set of candidate 
missions, describe their ATB requirements and define major tasks required for 
the ATB implementation. This plan will also offer alternative system con- 
figurations and suggest a phased approach to the ATB development. 
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1.4 DEVELOPMENT PLAN APPROACH 


In the first phase of implementation, the ATB is viewed as two separate 
systems that will be developed in parallel. They are (reference figure i-1) 
the Engineering Analysis/Simulation (EAS) System and Hardware Testing System 
(HTS) further described in subsequent sections. In the second phase of imple- 
mentation an ATB Management System (AMS) Function is proposed to coordinate 
the parallel development of EAS and HTS and to eventually provide system level 
planning and computerized control functions between the areas for hardware 
evaluations. The ATB Management System Function also includes hardware that 
is necessary to manage a distributed processing test facility. Distributed 
processing is a data management technique that permits geographically 
separated interactive or independent operations. 



♦Initially this will be a Management function only with hardware to implement 
system as requirements evolve. 

Figure 1-1.- Avionics Test Bed overall block diagram. 

1.5 ATB UTILIZATION SUMMA RY 

Table 1-1 reflects a forecast of potential ATB uses in the coming decades. 
The tasks or programs listed are based on a sampling of future space, 
commercial and defense programs and their potential needs for avionics systems 
development. Predicted activity within the ATB areas is marked with an X. A 
dash or hyphen in a column indicates an area of uncertainty to be clarified at 
a later date. NA means the program activity is not applicable to the ATB as 
currently predicted. An analysis of the ATB uses is in section 2. 
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TABLE 1-1.- ATB UTILIZATION SUMMARY 
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2. ATB UTILIZATION ANALYSIS 


2.1 INTRODUCTION 

Utilization of the ATB is tied to avionics definition and development for 
space flight in the future decades. In this section a forecast of potential 
ATB utilization is developed based on a sampling of future space programs and 
their potential needs for avionics development. The utilization analysis also 
leads into some organization and management concepts for the ATB. These ideas 
are offered as they occur in this section. The integrated management plan is 
presented in section 7. 

2.2 UTILIZATION OVERVIEW 

The basic data for the forecast and recommendations is organized into the 
matrix of table 1-1 in section 1. The columns in the matrix depict the 
typical activity phases of laboratory utilization for avioni: systems 
development and analysis as practiced by ASD. The rows of the matrix comprise 
a scenario of planned and conceivable space programs which would be served by 
the ATB concept. The elements of the matrix then constitute a model for ATB 
utilization. Entries were developed tlirough interview and analysis with 
various individuals in the Division and reflect their perceptions of how the 
ATB would be used for the various programs. Dashes signify areas of 
uncertainty to be clarified at a later date. NA indicates the activity is not 
predicted for use. 

2.2.1 NON-REAL-TIME (MATH MODEL) SIMULATION 

Design concepts are analyzed initially in non-real -time (NRT) simulations to 
assess feasibility. This phase is represented in column 1 of the matrix and 
by figure 2-1 in the generic example. These time-domain simulations (other 
software-based analytical methods, such as frequency-domain analysis, are 
considered outside the ATB domain) are then maintained and enhanced to track 
the maturing development program, or shelved if the program does not come to 
life. In the example scenario, as illustrated in figure 2-1, early design 
concepts for the control algorithm are evaluated against dynamic flight 
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simulations, Including flexible structure dynamics. The four basic blocks 
shown In the figure: 

• vehicle attitude stability and control 

• vehicle (rigid body, traditionally) dynamics 

• flex struc.'/rt control algorithm (under study) 

• flex structure dynamics simulation 

are resident In the laboratory computer (or computers), and are executed In 
demand or batch (but non-real -time) mode. 
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Figure 2-1.- NRT math model. 
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2.2.2 REAL-TIME (MATH MODEL) SIMl'LATION 

For programs where manual pilot characteristics are Important, a Man-In-the 
Loop (MIL) cockpit with appropriate scenes, displays, and control devices Is 
added, necessitating the real-time execution of the simulation. Column 2 of 
the table 1-1 matrix represents this phase, and figure 2-2 Illustrates the 
structure for the generic example. Generally the MIL cockpit at this phase Is 
oriented toward functional fidelity with displays, controls, and scenes 
necessary to do the analysis and, neglecting high fidelity details of a crew 
station mockup. Is used for layout design or procedures development In the 
Displays and Control Lab. 

2.2.3 HARDWARE SYSTEMS TESTING (LOCAL LAB) 

Roughly concurrent In time with the NRT simulation math model analysis, 
hardware evaluations are made i:’ the appropriate hardware laboratories. This 
phase Is represented In column 3 of the table 1-1 matrix. First, basic hard- 
ware characteristics are tested. Figure 2-3 Illustrates this for the generic 
example where controller microprocessor speed, memory, and data Interface 
characteristics and requirements are evaluated. The*‘.e evaluations are con- 
ducted on a local basis without significant Interaction with other ASD 
laboratories. As algorithms and system models emerge from the NRT simulatloi: 
efforts and other sources, this software Is utilized i.i more detailed testing 
of the hardware. Figure 2-4 illustrates this for the flex structure 
controller development where control algorithms are executed In the control 
microprocessor against some representation of the flexible structure dynamics. 
At this stage in the development, representations of the same hardware or 
software may exist in separate laboratories. Here arises the first need for 
the ATB Management System (AMS) function described later. Concepts of 
efficiency and commonality suggest that a central control and monitor of these 
activities would enhance the merging and integration of data and results and 
ease complex integration tasks later In the program. Also the possibility 
exists to utilize the same laboratory computer facility for the testing in the 
configuration of figure 2-4 as that used in the simulation activities of 
figure 2-1. 
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Figure 2-3.- Controller hardware evaluation. 
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Figure 2-4.- Controller system evaluation (HTS). 

2.2.4 MULTI-LAd (ATB) TESTING 

The ATB phase is represented by column 4 of the Table 1-1 matrix. Figure 2-5 
Illustrates the multi-lab configuration for the generic example. Testing 
involves two or more local laboratories in an integrated mode. In the generic 
example, the control microprocessor hardware and software art linked with the 
dynamics simulation, including the MIL Cockpit, in a real-time, man-in-the- 
loop simulation. A major goal of the ATB concept is to provide means for 
transfer and common utilization of major pieces of simulation software and 
technology among the various elements of ASO and at appropriate levels of the 
ATB. 


2.3 PROGRAM EXAMPLES 

In the following program examples the concept of levels is used for clarity. 
The concept is illustrated in the ATB configuration diagram. Figure 2-5. For 
ATB purposes, there are two levels. Activities which span at least two ATB 
functions are defined as Level 1. All Level I activities are the 
responsibi 1 ity of the AMS. Level 2 activities are confined to individual ATB 
functions. All Level 2 activities are accomplished in local laboratory modes. 

Four programs were selected from the list in table 1-1 to provide specific 
examples of ATB configuration requirements and to serve as departure points 
for more detailed sizing and costing studies. Two Shuttle enhancements were 
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selected, IMU upgrade (sensor development) and RCS enhancements (effector 
development), as typical of requirements for ongoing Shuttle work. The PEP 
program was selected because of the readily available reservoir of information 
on PEP requirements and because the activity reaches outside the more 
traditional GN&C laboratory configurations. SOC is a key new manned space 
flight program, and the ability to address SOC avionics development needs is 
fundamental to the ATB. A presentation of these four program examples as they 
relate to the ATB and ATB requirements follows. 

2.3.1 IMU UPGRADE (SENSOR DEVELOPMENT) 

The IMU upgrade program example is shown in figure 2-7. Initial analysis and 
development occurs at level 2 in the EAS laboratory and in the navigation and 
control subsystems laboratory. In the EAS laboratory, emphasis is on analysis 
and development of flight algorithms for inertial navigation and attitude 
control using IMU data, and with development of algorithms and procedures for 
IMU redundancy management. Non-real-time simulations are the primary mode in 
this example. The MIL cockpit and real-time simulation would be utilized when 
pilot dynamics are a key part of the system time response, primarily in the 
attitude control system development. In the navigation and control subsystems 
laboratory, testing is oriented toward development of inertial subsystem 
hardware and algorithms and interfaces for processing the hardware data. IMU 
redundancy management is also evaluated, primarily with trade studies to 
define partitioning requirements for data processing among remote 
microprocessors and the central computer. Level 2 tests are managed and 
conducted autonomously within the individual laboratories, but interfaces 
which w*;i, span multiple laboratories during level 1 are identified and 
managed at level 1. Also, level 2 software which has wider application during 
level 1 or other level 2 testing is identified and controlled by level 1. The 
level 2 interface across the two laboratories is made through the AMS 
function, illustrated in figure 2-7, and level 1 testing becomes the 
responsibility of the AMS organization. Level 1 testing provides high- 
fidelity dynamic response data on the combined IMU hardware and software. 


LEVEL 2 
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Figure 2-7.- IMU upgrade (sensor development) program example. 

















2.3.2 RCS ENHANCEMENTS (EFFECTOR DEVELOPMENT) 

The RCS enhancements development is illustrated In figure 2-8. Flow from 
level 2 to level 1 is much like the IMU example in the previous paragraph. 
RCS redundancy management and jet select algorithms are developed and analyzed 
in the analysis laboratory against math model dynamics and the RCS digital 
autopilot. Microprocessor hardware, software, and data interface testing 
occurs in the data systems laboratory. RCS driver electronics and data 
interface hardware are tested in the navigation and control subsystems 
laboratory. Intermediate levels of testing involving two or three of the 
laboratories may be required. Any combined laboratory testing is the 
responsibility of the AMS, with the full -up level 1 configuration illustrated 
in figure 2-8. 

2.3.3 PEP PROGRAM 

The level 2 configuration for the PEP program is shown in figure 2-9. In the 
analysis laboratory, the principal effort is directed toward analysis of the 
interaction between the Orbiter digital autopilot and the RMS control system 
and the development of solutions to dynamic stability and control problems. 

The principal mode is non-real -time simulation, with the MIL cockpit added to 
study manual operations. Testing in the power distribution laboratory 
evaluates PEP power conversion, distribution and control, and the power 
interface with Orbiter systems. Testing in the flight control laboratories 

evaluates sun sensors, pointing and tracking controls, and control dynamics. 

The level 1 configuration is shown in figure 2-10. The interface between the 
analysis laboratory, flight controls, and the power system laboratory is made 
through the AMS. Closed-loop testing, including manual modes, is conducted to 
evaluate PEP control interactions with RMS and Orbiter control systems and to 
assess dynamic effects of Orbiter/RMS manual and automatic control modes on 

PEP power system performance. 

2.3.4 SOC PROGRAM 

SOC is a major new program which is expected to be a principal user of the ATB 
capability. Since the Shuttle vehicle will serve as the base for construction 
and resupply of SOC, Shuttle test and simulation capabilities will form the 
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Figure 2-8.- RCS enhancements (effector development) program example. 
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Figure 2-9.- PEP program example - level 
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Figure 2-10.- PEP program example - level 










basis for Initial Orblter-centered SOC rendezvous, proximity operations, and 
deployment simulations. As SOC systems are defined In sufficient detail, SOC- 
centered simulation and test activities will evolve through the typical ATB 
sequence, described by the generic example of section 2.2. ATB utilization 
for SOC, then evolves on two primary fronts: 

1) Orblter-centered: utilizing primarily math model simulation of joint 

OrbIter/SOC operations. Hardware development laboratories are used when 
new or enhanced Orbiter avionics are evaluated for the SOC mission. 

2) SOC-centered: utilizing the full ATB capability for SOC avionics develop- 

ment. A full complement of simulation, hardware testing, and joint 
hardware/simulation operations capabilities Is required to support SOC 
development. 

The ATB configuration and management concepts, as defined here and in sec- 
tion 7, are fully supportive of SOC development. The three program examples 
given In previous sections could serve equally well as SOC avionics develop- 
ment examples utilizing ATB. A full -up level 1 SOC avionics development 
configuration, using the drawing format and conventions of previous sections 
is shown in figure 2-11. The basic ATB configuration Is Intact, and organi- 
zational roles and responsibilities are easily identifiable. Including the 
AMS. Finally, the ATB configuration as recommended, given sufficient 
computation and data flow capacity, can support full dynamic simulation, 
including hardware loops, of SOC and Orbiter jointly for rendezvous, proximity 
operations, docking, and cooperative control studies. 
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Figure 2-11.- Full up (level 1) SOC In ATB 







3. ATB SYfTEM OVERVIEW 


As shown in figure 1-1 in section 1, the ATB may be divided into three major 
functional areas, EAS, AMS, and HTS with sub-functions as shown in figure 3-1. 
Some of the activities are listed on the figure 3-1 in each of the major func- 
tional areas and for the HTS sub-functions across the bottom of the figure. 
The areas and functions shown are as follows: 

1. Engineering Analysis/Simulation System (EAS) 

2. ATB Management System (AMS) 

3. Hardware Testing System (HTS) 

• HTS Data Management Function 

• Navigation Aids and Guidance Function 

• Flight Control Function 

e Displays and Control Function 
a Electrical Power and Distribution Function 

• SAIL STS and GTS Interface Function 

Early ATB development will be concentrated on the EAS and HTS with the AMS 
function coordinating the development effort. The AMS will be initially a 
management function only, but will become an actual computer based system as 
operational requirements evolve. The EAS and HTS can be operated indepen- 

dently and simultaneously. 

The functional areas are linked by four major data, voice, and video communi- 
cation networks. Figure 3-2, ATB Functional Block Diagram, defines the func- 
tional areas and their four communication networks. The networks are 

described as follows: 

1. The Simulation Network (SN) is CDC's Loosely Coupled Network (LCN) - a 
50 megabit/second serial link that is compatible with CYBER and DEC com- 
puters. This data link will provide a high speed bidirectional serial 
communications link between the EAS and HTS. This link has a large 
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geographic sepa.atlon. The purpose of this link Is to transfer EAS 

environment parameters to the HTS for distribution to Its six functional 
areas and to return reaction parameters to the EAS math models. 

2. The Data Management Network (DMN) utilizes MIL-STD-1553B communication 
protocol (1 megabit /second) with an In-house designed terminal multi- 
plexer. This Is the avionics system network that will be used to inves- 
tigate data bus electrical specifications, protocols, redundancy manage- 
ment, and system configurations. The data content for this network vMll 
be depicted by the Investigation. 

3. The System Management Network (SMN) Is for system Initial condition, 
configuration control, data acquisition, and environment interface, and 
will utilize the Ethernet protocol (10 megabit/sec. ) . 

4. The Subsystem Managers Console Network (SMCN) Is a broadband voice, video, 

and data (14 megabit/sec. ) CATV communication link. This link will 

distribute scenes, test conductor's console communications, and broadband 
data. 

The compatibility of the networks and host computers offer a high degree of 
reconfigurability. Each of the networks and their protocols are either IEEE, 
MIL-STD, or industry proven; therefore, they are supported by several computer 
operating systems. For example, the CDC 50 megabit/second Loosely Coupleo 
Network Is supported by the CDC Remote Host Facility (RHF), IBM OS/MVS JES2 or 
JES3, and by the DEC RSXllM operating systems. DEC, In turn, supports 
Ethernet while Local Area Computer Network (LACN) supports high performance 
Ethernet. MIL-STD-1553B is an avionics network protocol used by -tany military 
missile and aircraft. MIL-STD-1553B Is similar to the Orbiter's data bus 
format; bit, due to a much larger market, many special very large scale 
integrated (VLSI) circuits are available to support hardware development. Its 
data bus electrical characteristics are identical to the Orbiter's data bus. 

Figure 3-3, Detailed ATB block diagram, breaks the functional areas shown in 
figure 3-1 into major system components. This configuration utilizes the 
present laboratory resources wherever possible. This ATB design allows 
multilevel reconfiguration, I.e., various combinations of the major functional 
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Figure 3-3.- Detailed ATB block diagram 































areas may be configured into one or more systems. In addition, the various 
functional blocks or laboratories can be reconfigured to either support a 
system test or subsystem test. One major concern in the ATB is in the system 
management area. A reconfigurable crew station and system managers display/ 
control console will be required. These systems should utilize advanced touch 
sensitive display terminals. This allows "soft" display and control switches 
that can be built by software for each test configuration. 

The following design goals were selected for the ATB system configuration 
shown in figure 3-1. 

e Cost control through use of commercially available communication networks, 
operating systems and cor.iputers. 

• Multilevel reconfigurability 

• Maximum utilization of ASD laboratory resources 

• Minimize new hardware and software design using commercially available 
equipment 

• Centralized display and integration of distributed tests 

• Each ASD laboratory maintains its sovereignty 

• Phased design allows future expansion to LSS system ctudies 

• ASD laboratories remain in place by geographic distribution of data 
processing 

• Local processing at each netwoi'k terminal reduces overall throughput 
requi rements 

• Reduce software rewrite through use of advanced operating systems and 
languages such as FORTRAN 77 and Ada 

• Phased design approach supports early test capabilities 

• Alternative configurations must not impact ATB objective 

• Cost control through use of MIL-STD instruction set architecture such as 
Air Force MIL-STD-1750 16 bit and Army MIL-STD-1862 32 bit instruction 
sets. Instruction set architecture standardization will reduce software 
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cost in three ways: 1) permits a common set of support software tools, 

2) transportcbi 1 ity of operational code modules, and 3) enhanced programmer 
fami liarity. 

The following paragraphs will discuss the capabilities in each of the 
functional areas. 

3.1 ENGINEERING ANALYSIS SIMULATION SYSTEM FUNCTION 

EAS performs three major functions in the context of the ATB. The first two 
functions are stand-alone EAS (Level 2), requiring no physical interface with 
the remainder of the ATB. The third function supports the multi -lab ATB 
(Level 1). 

3.1.1 NON-REAL-TIME (MATH MODEL) SIMULATION 

These large-scale, time domain dynamic simulations are used for analysis, 
development, and verification of design concepts. An example is the Space 
Shuttle Functional Simulator (SSFS), which simulates all Shuttle flight phases 
(ascent/GRTLS, orbit, entry), at varying levels of detail, depending on 
analysis requirements. The program comprises 50-thousand lines of FORTRAN 
code (negligible assembly language), with runtimes ranging from seconds to 
several hours on tne Uni vac 1110, depending on the application. Study areas 
typically include stability and control; altitude and pointing analyses; 
guidance and navigation analyses; and guidance, navigation, and control 
software and sy:tum integr.'ition studies. 

3.1.2 REAL-TIME (MATH MODEL) SIMULATION 

These simulations incorporate the essential element of systems for manned 
flight: the pilot. To simulate the ci^'amics of the pilot's response, they 

must execute in real time, and they must provide adequate realism at the pilot 
interface, i.e., scenes, displays, and controls. An example is the Shuttle 
Engineering Simulation (SES), which performs MIL simulation studies of Shuttle 
ascent/GRTLS, orbit (including remote manipulator system), and entry. 
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3.1.3 MULTI-LAB (ATB) TESTING 

In the performance of this function, the EAS provides dynamics, environments, 
and flight system simulation support to the NTS elements of ATB. To support 
hardware testing, the simulation must necessarily execute in real time. 
Simulation fidelity, MIL cockpit (if any), math model, and flight system 
simulation requirements are dictated by individual studies. 

3.2 ATB MANAGEMENT SYSTEM FUNCTION 

The AMS function is the only area of the ATB that is totally new. The AMS 
functional responsibilities include the following items: 

• Test configuration and control 

• Test initial condition of synchronization 

• System scenes generation 

• Scene distribution network 

• Intralaboratory voice communication 

• System managers display/control 

• Crew station simulation 

• System data base for test procedures, recorded system test data, and system 
configuration records 

• Data distribution to subsystem managers consoles 

The AMS function has access to the System Management Network, HTS Data 
Management Network, and the Subsystem Managers Console Network. This 
configuration provides the AMS with high speed communication to all ATB 
subsystems. 

One mainframe computer (VAX 11/780) drives all AMS Functions. This computer 
system operates in a shared memory multiprocessor configuration with the HTS 
VAX computer system providing very high speed data link to the EAS function. 
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3.2.1 SYSTEM MANAGERS CONSOLE 


The System Managers Console design allows complete reconfiguratio.i by the 
utilization of flat screen touch sensitive television or plasma displays. All 
displays, labels, and control switches will be "soft". The same design 
concept will be used on the crew station where special CRTs for NAV AIDS will 
enhance reconfigurability. 

3.2.2 SCENE GENERATOR 

A TBD scene generator will provide high resolution scenes at the crew station 
while LACN (a CATV network) distributes scenes by compatible television to 
each of the subsystem managers consoles. Recent network designs have utilized 
CATV for voice, video, and broadband data communication on a single coaxial 
trunk. A large commercial market for CATV components makes this type of 
network economical. 

3.2.3 SYSTEM DATA BASE 

A major responsibility of the AMS Function is to initialize tests, control 
tests via test procedures, and record results for post test data analysis. 
The system data base provides this function. 

All system test procedures are controlled by the system management console 
computer. This allows accurate repeatability of tests. This function is 

critical in a geographically distributed processing system such as the ATB. 

3.3 HARDWARE TESTING SYSTEM FUNCTION 

The hardware testing system has six functional areas that are interfaced by 
the DMN. Figure 3-2 showed the HTS and its six functional areas enclosed 

within dotted lines. The following paragraphs describe each of the HTS 
functional areas. 

3.3.1 HTS DATA MANAGEMENT FUNCTION 

The HTS Data Management Function controls and manages all avionics subsystems 
••ia the Data Management Network. This network utilizes the MIL-STD-1553B data 
L > protocol and electrical specifications. 
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The MIL-STD-1553B data buses are being used in many new aircraft designs such 
as the F16. The Orbiter data bus is a forerunner of MIL-STD-1553B and is very 
similar electrically; however, there are many more MIL-STD-1553B components 
commercially available for data bus development. The Data Systems Branch has 
done some development on a Data Management Network that is totally distributed 
with no centralized control processor. This feature is very advantageous in 
reconfiguration. 

The Data Management Network will provide a standard computer based terminal 
for each node of this network. All hardware prototyping or subsystem 
experiments will interface the ATB via this standard Data Management Terminal 
(DMT). A special DMT will interface the Analysis Function through a Data 
Management computer. This terminal may act as multiple DMTs during system 
tests. 

A subsystem has the following DMT interface options: 

e MIL-STD-1553 • IEEE 488 or HIB • ORBITER DATA BUS 
• RS 232 • MULTIBUS (INTEL BUS) 

The DMT provides software for the Data Management Network protocol and 
subsystem interface option. The DMT hardware that supports the Data 
Management Network is modular and each terminal may have from 1 to 4 MIL-STD- 
1553B data buses on one DMT. The DMT will have Remote Power Controllers (RPC) 
integrated into its bus interface. It is; however, the responsibility of the 
Electrical Power Distribution and Control Lab to design and control the RPCs. 

3.3.2 FLIGHT CONTROL FUNCTION 

The Flight Control Function will utilize the Flight Controls laboratory in the 
development of hardware such as accelerometers, rate gyro, thrusters and other 
types of effectors. This function will communicate with other ATB functions 
via the Data Management Network. 
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3.3.3 NAVIGATION AIDS AND GUIDANCE FUNCTION 


The Navigation Aids and Guidance Function will conmunlcate with the avionics 
system via the Data Management Network. This function has the development 
responsibility for navigational sensors. 

• IMU • Global Positioning System 

• TACAN t Rendezvous Radar 

t Air Data • MSBLS 

• Radar Altimeter e Star Tracker 

• Airborne Accelerometer 

3.3.4 DISPLAYS AND CONTROLS FUNCTION 

The ATB Displays and Controls Function will be responsible for the development 
of HTS crew stations within the ATB. This development effort will include the 
investigation of advanced techniques such as color graphic displays, voice 
entry systems and voice annunciation for caution and warning. This function 
will also investigate the human factors interactions of the crew to the avion- 
ics systems with both touch sensitive display and computer voice systems. 
This will reduce training requirements. 

It is proposed that caution and warning and instrumentation be under the 
Displays and Controls Function. 

3.3.5 ELECTRICAL POWER DISTRIBUTION AND CONTROL FUNCTION 

The EPDC laboratory will be utilized to test and evaluate the Orbiter 
interfaced alternate power sources such as PEP or SOC. This function will 
also be responsible for developing automated power distribution and control 
within the HTS Data Management Network. 

This function will continue to investigate high voltage distribution for 
future LSS such as SOC and PEP primary power systems. 
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3.3.6 SAIL STS AND GTS INTERFACE FUNCTION 

The SAIL STS and GTS Interface Function (SSGIF) is responsible for the 
interface between the ATB and SAIL. This interface requires further study. 
Figure 3-1 is one example of a SSGIF under AMS utilizing a DMT with an Orbiter 
data bus option. 

3.4 ATB OVERVIEW CONCLUSION 

This concludes the functional overview of the ATB system. The following 
sections will describe a parallel development philosophy in the EAS and NTS 
systems with the AMS serving as system project management. Both EAS and HTS 
are designed to provide early independent operations, i.e.; each system can 
contribute to the program during this development effort before a full ATB is 
operational . 
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4. ENGINEERING ANALYSIS SIMULATION 


EAS is the analysis and simulation element of ATB. For this presentation it 
is restricted to time-domain simulations with current or anticipated real-time 
applications. This excludes, as part of EAS, all non-time-domain applications 
software and time-domain simulations which have no anticipated real time 
applications. Designation and control of software as part of EAS is a Level 1 
function as explained in section 2. 

An overview of EAS use and relationships with the rest of the ATB is given in 
Section 2. Top-level EAS requirements are described here and a development 
plan for EAS is offered. The intent is to set down requirements for the EAS 
as a subset of the ATB. Design and development of the EAS computation system, 
as well as definition of any non-ATB requirements for that system (such as 
hosting large-scale engineering applications software), are outside the scope 
of this presentation. 

4.1 EAS REQUIREMENTS 

As depicted in Figure 4-1, EAS is comprised of two elements, the MIL cockpit 
and the computation system. Requirements for these two elements are described 
in the following paragraphs. 

A hardware system configuration for EAS is included here for completeness. 
This configuration is an example only, and no recommendation is offered or 
intended regarding the merits of this configuration in competition with any 
others. The example hardware configuration is comprised of three Control Data 
Corporation (CDC) mainframe computers linked through Simulation Network (SN), 
CDC's local network system Loosely Coupled Network (LCN) for this example and 
CDC Network Operating System (NOS). The LCN provides local network inter- 
connect for host-to-host access for a variety of mainframes including IBM 370 
and DEC Virtual Address Extension (VAX). The EAS is linked to the other ATB 
functional areas via the SN and a DEC VAX 11/780. The SN uses a single 
coaxial trunk as a communication mechanism. 
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In this example, the EAS Shuttle Engineering Simulator Is Interfaced via a SEL 
32/55 to support Urbiter enhancements. The mainframe computer network 
provides realtime simulation flight dynamics, environments, and required 
elements of the flight systems. The environments are communicated to the 
various hardware prototyping Interfaces via the SN and finally through the HTS 
Data Management VAX computer system. The HTS Data Management VAX system uses 
two networks, MIL-STD-1553B for data management network communications and 
Ethernet for environment communications. The HTS Data Management VAX computer 
system can also operate as a stand alone environment simulator for a variety 
of hardware prototyping tests. This system configuration frees the EAS for 
other level 2 tasks. 

Computation system size and speed requirements for EAS have not been quanti- 
fied, nor have EAS to HTS Interface data rates been defined. The major driver 
In both instances is the simulation In real time of large flexible structures 
and the systems necessary to stabilize and control such structures. Some 
studies have been undertaken to define LSS computation system and interface 
requirements, but only estimates have been made available to date. The data 
and technology necessary to define the simulation requirements Is readily 
available, and early initiation of such a study is strongly recommended. 

4.1.1 OPERATING MODES 

Three operating modes are required for EAS: 

• Batch mode for background execution of large-scale simulation problems, 
which may incorporate Iterative or Monte Carlo techniques. 

• Demand mode, with multiple ports, including support to interactive 
terminals. 

• Real-time mode, either stand-alone EAS (level 2), Including closed-loop MIL 
simulations, or supportive of hardware laboratory elements of ATB (level 1). 

4.1.2 SOFTWARE PORTABILITY 

A key factor in the efficiency and utility of ATB is software portability. 
Development and maintenance of multiple versions of software to do the same 
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Job Is wasteful and unnecessary. The implementation of level 1 standards and 
requirements for ATB software portability will eliminate this waste by ensur- 
ing that code developed and maintained for applications In one area Is most 
easily used for the same or similar applications In other areas. For example, 
code developed and maintained for NRT applications should be executable for 
real-time applications, and transportable as required for special applications 
In hardware laboratories. 

4.1.3 USER ACCESS 

Hands-on accessibility to EAS for development of NRT applications software Is 
required. Access Is required via batch and demand modes for development and 
analysis of GN&C and other applications software. 

4.1.4 MIL COCKPIT 

The MIL cockpit is comprised of three elements: displays, controls, and 
scenes. Requirements for these three elements. Individually and collectively, 
will vary widely, depending on study objectives. In general, the requirements 
are functional, to quantify the dynamics of the system with the man as a part 
of it. The MIL cockpit Is not required as a cockpit design tool, nor is it 
suitable for crew training or crew procedures development. 

4.2 EAS DEVELOPMENT PLAN 

The bulk of EAS activities in the ATB timeframe will Involve orbital flight 
simulation. Some Shuttle enhancement ascent and entry studies may be re- 
quired, along with other programs like the all-electric airplane, but most of 
the programs identified in table 1-1 are directed toward orbital operations. 
Specifically, the two programs of highest interest at JSC are the Shuttle and 
its transition into a platform for performing orbital operations, and SOC. A 
plan for development of EAS orbital simulation capabilities is presented in 
figure 4-2. The plan includes some parts of current or planned activities in 
ASO and other divisions. The plan is not intended to account for, nor to 
constrain those activities, but rather to give an overview of requirements for 
EAS in support of the Shuttle and SOC. 
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Figure 4-2.- EAS development plan. 






In figure 4-2, the circled labels Identify major simulation capabilities. The 
smaller circles signify summations or Joining of the Input capabilities. The 
milestone triangles with flags Identify major study requirements as they occur 
In the flow. The calendar scale Is for reference. 

Current capability as Identified in figure 4-2, Is contained In the combina- 
tion of SSFS (see paragraph 3.1.1) and SES (see paragraph 3.1.2). SSFS Is 
presently resident on the Univac 1110 system at JSC, Building 12, with 
conversion to the CDC system at JSC Building 16, scheduled for mid-year, 
1982. Following conversion, as shown In the figure, flexible payload, 
proximity operations, rendezvous, and flexible orbiter autopilot studies will 
be performed. SES Is resident In the SEL computer complex at JSC Build- 
ing 16. For th? on-orbit mission phase. It Is used primarily for MIL simula- 
tion studies of the RMS and manual proximity operations. Studies are In- 
progress to plan the most efficient use of SSFS and SES and their host 
computer systems In Building 16. 

The plan Is divided into two segments, payload development and Orbiter -devel- 
opment. The payload segment is comprised of one main sequence, starting with 
a rigid free payload capability, adding flexibility, with comolned Orbiter 
simulations at appropriate points In the sequence. Payload simulation capa- 
bil1t> Includes attached or deployed payloads as required, leading up to simu- 
lation of SOC element deployment, retrieval, and docking operations, including 
RMS. The Orbiter segment contains two main sequences, the rigid, free vehicle 
sequence, and the flexible vehicle sequence, which Includes RMS cap-^L; i 1 Ity. 
Common to the two Orbiter sequences is the RCS DAP, the essential element In 
any six-degree-of-freedom simulation capability. The rigid, free vehicle 
sequence incorporates rendezvous radar. Guidance and Navigation (G4N), and 
thrust capability, all direrted toward long-range trajectory dynamics simu- 
lation of rigid vehicles. The flexible vehicle sequence incorporates flexible 
orbiter dynamics, along with flexible payload and RMS capability, as appro- 
priate for detailed stability and control analyses. 

Eight major study areas are identified in figure 4->. These are described In 
the following paragraphs. 
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Pi-Rigid Payload (Payload Free Sequence) 


Stability and control of rigid free fliers, including pointing, maneuvering, 
orbit maintenance studies. Primarily directed toward definition and analysis 
of SOC onboard system requirements. 

P2-Flexible Payload (Payload Free Sequence) 

Stability and control of flexible free fliers. Flight control interaction 
with flexible structures, including definition structure of loads resulting 
from flight control activities. Primarily directed toward definition and 
analysis of SOC onboard system requirements. 

PRl-Prox Ops - DAP (Payload/Rigid, Free Vehicle Sequences) 

Manual mode, Orbiter based proximity operations studies directed toward defi- 
nition and development of Orbiter manual flight control mode requirements for 
proximity operetions. 

PR2-RDZ, Prox Ops (Payload/Rigid, Free Vehicle Sequences) 

Manual and automatic rendezvous and p'-oximity operations studies to develop 
and enhance long-range to close-in Orbiter system requirements. 

Fl-DAP, OEX DAP (Flexible Vehicle Sequence) 

Studies to define DAP requirements for stability and control of a flexible 
Orbiter, directed primarily toward definitions and analysis of the OEX DAP. 

F2-DAP/RMS - Unloaded (Flexible Vehicle Sequence) 

Studies to define DAP and RMS control system requirements for system stability 
and control . 

PFl-D A P/Pay l oad Deploy (Payload/Flexible Vehicle Sequences) 

Studies to define Orbiter DAP requirements for stability and control through 
mate/deploy mate sequences for flexible payload. Also allows for cooperative 
control studies with Orbiter and payload control systems active. 
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PF2-DAP/RMS - With Payload 


Studies to define Orbiter DAP and RMS control system requirements for system 
stability and control, including flexible payload effects. 
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5. HARDWARE TESTING SYSTEM 


The HTS will be analyzed operating in the independent mode as shown in fig- 
ure D-1. The major difference in this operation is the source of simulated 
environment. In a full -up operational ATB system (not independent mode), the 
environment models may be resident in either the EAS mainframe computer or the 
HTS interface computer. The HTS interface computer will provide low resolu- 
tion simulations in the independent mode. Note that the interface between the 
two systems is considered to be part of the HTS. This interface has the VAX 
11/780 computer (shown in figure 3-3) as part of the network distribution/ 
muliplexer between the EAS and HTS. One reason VAX 11/780 was selected as the 
multiplexer interface between the HTS and the EAS is because it is compatible 
with hardware and software of the CDC loosely coupled network (LCN). . This 
allows the VAX 11/780 to be located remote to the EAS area. It is recommended 
that the VAX 11/780 be located in the Data Systems laboratory which is in 
close proximity to the HTS development area. 
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Figure 5-1.- ATB independent operational mode. 

The proposed VAX 11/780 will support multiusers allowing it to be the software 
development computer for the HTS microprocessors. This system has cross 
compilers and assemblers for most of the 16 and 32 bit microprocessors. It 
also is targeted as one of the first host computers for a certified Ada 
compiler. These are the major reasons for selecting a VAX 11/780 as the HTS 
computer. 

During early HTS development the VAX 11/780 will provide the system simulation 
environments. Figure 5-2 is a graphic example of the VAX 11/780 in the early 
development of the ATB. It is proposed that Ethernet be used to distribute 
simulated parameters within HTS. The same Ethernet configuration will also be 
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Figure 5-2.- VAX 11/780 independent operating mode. 
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used for distribution of simulation parameters from EAS with the VAX 11/780 
used as an interface and multiplexer. The VAX 11/780 is also targeted as one 
of the first systems for Ethernet. 

5.1 HTS PROJECTED TASKS 

The HTS design objectives include the design goals stated for the ATB and in 
addition will provide an engineering test facility for the following tasks. 

5.1.1 HTS DATA MANAGEMENT TASKS 

The HTS Data Management tasks include: 

• Evaluating distributed system techniques 

• Developing redundancy management techniques for distributed systems 

• Developing procedures for partitioning and allocation of avionics tasks in 
a distributed system 

• Developing a Time Distribution System for a SOC Avionics System 

• Developing Data Management System Configuration for SOC 

• Evaluating data bus configurations for SOC Avionics System 

a Developing microprocessor architectures that reduce the cost of software 
development through the use of high-level Languages such as Ada 

• Investigating the use of Programmable Logic Arrays and Array Arithmetic 
processors as a cost effective method of increasing the maximum operation 
rate of processors 

• Investigate MIL-STD-1750 microprocessors such as the 9450 

• Investigating Dynamic Task Reallocation 

• Evaluating mass memory technologies 

• Investigating mass memory configurations 

• Evaluating error detection and correction techniques for use in avionic yP 
solid state memories. 
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5.1.2 ELECTRICAL POWER AND DISTRIBUTION TASKS 


Electrical power and distribution HTB tasks include: 
e Developing Automated Power Management techniques 
t Developing Automated Power Distribution and Control techniques 

• Investigating switching mechanism for redundant resources (powered vs. 
unpowered redundant set) 

• Evaluating high voltage distribution (AC vs. DC) 

• Investigating power instrumentation and HV isolation techniques 

• Preparing requirements for a distributed fault-tolerant system 
e Investigating power control configurations 

• Testing advanced power components 

• Developing data bus controlled Remote Power Controller (RPC) 

5.1.3 DISPLAYS AND CONTROLS TASKS 
Displays and Controls tasks include: 

§ Developing better information-transfer methods by use of voice at crew 
station 

• Comparing various advanced display systems such as flat screen CRT, plasma, 
and LCD 

• Investigating crew station simplification and reduced system training 
requirements by use of stored procedures, touch sensitive displays and 
voice talkback 

• Developing "soft" switch/controls to reduce control panel retrofit as 
system configuration changes 

• Investigating use of color displays to enhance crew interface 

• Investigating use of standard computer terminal as crew interface 

• Developing system fault isolation techniques using crew station 
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5.1.4 FLIGHT CONTROL TASKS 


Flight Control tasks include: 

• Investigating new effector technologies 

• Developing and testing electromechanical actuator systems 

• Investigating control system redundancy management concepts 

5.1.5 NAVIGATION AIDS AND GUIDANCE TASKS 
Navigation Aids and Guidance tasks include: 

• Developing advanced inertial measurement systems 

• Conducting inertial systems performance evaluations 

• Investigating laser gyro technologies 

e Evaluating redundancy management concepts 
e Investigating new sensor technologies 

• 'Improving software utilization techniques 

5.2 DATA MANAGEMENT DEVELOPMENT SYSTEM 

Figure 5-3 shows the existing Data Management Development System, which is the 
basis of the preliminary HTS design. The present state of development 
engineering in this area has been concentrated on the development of a 
protocol using MIL-STD-1553B for autonomous communication between distributed 
microprocessors. Several important facts have resulted from this engineering 
task. 

1. The utilization of a high level language (FORTRAN IV) operating with a 
realtime multitasking software system in a microprocessor is feasible when 
most of the communication link overhead is controlled by hardware 
input/output processors. The system in figure 5-3 allows asynchronous 
communication between any two systems with or without software interven- 
tion. This is accomplished by a microprogrammed controller using direct 
memory access (DMA) and intelligent VLSI circuits to control all data bus 
communications. This system utilizes a virtual memory technique for high 
speed communication between system processors. 
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Figure 5-3.- Data management development system. 

























2. Time is very important in correlating distributed data terminals. The 
Master Timing Unit in figure 5-3 utilizes MIL-STD-1553B protocol trans- 
mitting at 100 us intervals. 

3. Multiprocessing (parallel processing) will be required for LSS avionics 
throughput requirements. Appendix A (separate supplement) expl^^ns by 
example, the gains in processor computation rate and volume by the use of 
multiprocessors. 

Refer to Appendix B (separate supplement) for details on HTS microprocessor 
evaluation. The following section is on the background information used in 
the selection of HTS microprocessor system. 

5.3 SELECTION OF HTS PROCESSORS AND SOFTWARE 

A major area of concern in the development of an avionics control system for 
LSS such as SOC is the control system processor speed requirements. Early 
estimates from SOC and LSS control systems studies indicate potential flight 
processor requirements of 20 to 50 MFOPS (million floating-point operations 
per second). This very high computation rate is required in flight control 
for vibration and damping due to very large arrays of sensors and effectors. 

This computation capability far exceeds the processors shown in figure 5-3 or 
the present Orbiter GPC. Array processing has been suggested as one possible 
solution; however, several recent technological developments may also provide 
a more general purpose solution to the problem. A VLSI 32 bit microprocessor, 
iAPX432, which uses an object-based architecture that is directed towards Ada 
as its primary programming language is available. This microprocessor has 
built-in hardware to support multiprocessing and redundancy checking, a highly 
desirable feature in avionics systems. The 1APX432 is a microprocessor with 
today's mainframe capabilities. Details on the 1APX432 is in Appendix B 
(separate supplement). 

It is not the object of this document to define a data management or avionics 
system configuration but to define hardware that is easily reconfigured for 
evaluation of many different system configurations while providing sufficient 
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computational speed to perform realtime control system simulations. Several 
assumptions were made In the defining of the hardware for NTS processors. 

• The system may operate with or without a DMT or a combination of both. 

• Ada will be the final language for the system, but due to necessaf 7 early 
development of the HTS, FORTRAN will be used until programmers are trained 
for Ada and certified compilers are available. 

• The objective of the HTS Is not to select a particular processor or 
processor architecture, but to evaluate distributed processing for avionics 
systems. 

• It Is assumed that no single processor will support more than eight data 
buses with a maximum of four active at any one instant. 

Although MIL-STD-1553B is considered the data bus protocol in this discussion, 
the design of the HTS general processor allows different protocol to be con- 
sidered because the protocol interface overhead is microprogrammed in hard- 
ware. Minor changes may be required in the software drivers if completely 
different protocols are evaluated. 

It is proposed that two major processors be available for use on the HTS: a 

minor processor and a major processor. Each processor will have the cap- 
ability of operating in any bus configuration and will have a multitasking 
operating system with drivers for each data bus. Application software and 
subsystem interfaces are all that are required by a user to implement a 
subsystem. In the simplest processor configuration, it becomes a DMT as 
described in section 3.3. Figures 5-4 and 5-5 demonstrate the two major 

processors. 

5.4 HYPOTHETICAL HTS CONFIGURATION 

Reference figure 5-6 for a conf igurition utilizing the HTS general processor. 
This figure defines a hypothetical system that has dual redundant regional 
processors set (Al, Bl) and (A2, B2). The redundant set (A1 , 81) share a dual 
redundant subsystem or local set of processors (SA12, SB12) and (SA21, SB21). 
The redundant processor set (A2, B2) has dual redundant data buses. Dual 
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Figure 5-5.- Independent HTS processor terminal. 
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Figure 5-6.- Hypothetical HTS configuration 








redundant global processors (BCA, BCB) are shown in dotted lines because 
proposed HTS processors can operate equally well with or without a bus 
controller under M1L-STD-1553B by the use of an automatic polling bus 
interface adapter. 

The redundant subsystem set (SA12, SA21) interface experiments via one of the 
ATB Processor interface options. 

e IEEE-488 • RS 232 

• MIL-STD-1553B • Orbiter Data Bus 

• MULTIBUS 

The two proposed HTS processors or DMTs have identical interface options and 
each may be operated with MIL-STD-1553B (eight maximum) configured as either a 
bus controller only, remote terminal only, software controller terminal, or 
automatic polling. 

The MIL-STD-1553B bus terminal interface allows a message transaction between 
two terminal units that consists of 1 to 32-16 bit words. The bus terminal 
interface provides a software controlled interface that is compatible with a 
High Order Language (HOL). All transfers between the bus terminal interface 
and the host computer occur under Direct Memory Access (DMA). The host 
computer can request a variety of options such as: 

• On line/off line • Buffer write protection (via busy states) 

• Buffer memory location • Status response 

• Interrupt after completion • Transmitter disable 

• Buffer size 

A typical avionics development system for SOC using the DMTs is shown in 
figure 5-7. 

Figure 5-8 defines the HTS MIL-STD-1553B command word format. The content of 
the data buffers and the protocol for their use is user defined thus providing 
a wide range of user configurations. 
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Figure 5-7.- HTS SOC avionics system block diagram. 
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Figure 5-8.- ATB MIL-STD-1553B comniand word format. 














A typical mode of operation might be system A requesting system B to pass 1 to 
32 words from output buffer n in an immediate mode. This message transaction 
may be completed with or without processor B software knowing the time of the 
transaction. 

5.5 GENERAL HT$ PROGRAMMING LANGUAGE 

Ada will be used exclusively in HTS except in areas such as embedded pro- 
cessors and during early development prior to release of Ada. 

Ada is the name of the DOD common high order language that is being developed 
by Defense Advanced Research Projects Agency (DARPA). Ada compi lers must be 

certified by DOD standards before release. Several corporations such as 
Intel, Honeywell, and Telesoft are nearing certification of Ada compilers. 
Ada evaluation workshops at Honeywell concluded the following: 

• Ada is readable and maintainable 

• Portable (machine independent) 

• Reliable - Ada reduces the amount of coding and, therefore, the chances of 
error 

• Modular 

§ Conceptually simpler to use in supporting multiprocessor computer systems 

Ada has a broad support base with DOD, academic, and industrial users. Tt ■'s 
proposed that all HTB software be developed in Ada computer language. 

5.6 EAS TO HTS INTERFACE 

A k> component in the development of the HTS area is a VAX 11/780. In 
review, the VAX 11/780 was selected because: 

• The hardware and software is compatible with CDC's Loosely Coupled Network 
for interfacing the Engineering Analysis/Simulation to HTS. 

• It supports Ethernet for geo^^.'aphic distribution of simulation parameters. 

• It is one of the first targeted computers for Ada certified compilers. 
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• Cross compilers and assemblers for most microprocessors are available. 
This will reduce the cost of software development by providing a common 
machine for software development. 

• It has field proven hardware/software for supporting realtime and batch 
operations. 

• It is a cost competitive system with many second sources for system 
components. 

e The throughput and computation capabilities can be easily increased either 
by addition of parallel processors or array processors. 

• The VAX 11/780 does not require special facilities such as 400 Hz power or 
chilled water. 

• The VAX 11/780 is equiped with a c"OSS assembler to the MIL-STD-1750 16 bit 
and MIL-STD-1862 32 bit inscruction sets. 

The proposed VAX 11/780 packaged system is configured with: 

• 1 megabyte of ECC MOS memory 

• an REM80 single access 124 megabyte disk drive with MASSBUS Adapter 

• a TEU77 (125 inches/second, 800 or 1600 bpi) magnetic tape transport unit 
with MASSBUS Adapter 

• an LA-120 DECwriter III console terminal 

t and a BAll-K expansion mounting box containing Oiie DDll-DK expansion 
backplane mounting unit and one DZll-A asynchronous multiplexer for 
connection of eight EIA STD communication lines 

• a high performance floating-point accelerator (FP780-AA) 

5.6.1 OPERATING SYSTEM 

VAX/VMS is the general-purpose operating system for VAX systems. It provides 
a reliable, high performance environment for the concurrent execution of 
multiuser timesharing, batch, and realtime applications written in BASIC, 
COBOL, FORTRAN, PASCAL, BLISS, CORAL, PL/I, and assembly language (which is 
included with the operating system). 
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The system features virtual memory management, event-driven priority 
scheduling, shared memory, file, and interprocess communication, data 
protection based on ownership and application groups, user privileges and 
resource allocation control, and an easy-to-use, easily extended command 
language. 

Other system features include multijob batch processing, program development 
tools, extensive file and record management services, programmed system 
services for process and subprocess control and interprocess communication. 
Common Run-Time Procedure Library, and system maintenance utilities. 

The VAX/VMS product includes the following facilities: Operating system 
nucleus, including virtual memory manager, swapper, system services, and 
input/output device drivers; user authorization control program; job initiator 
account manager; and operator communications manager. 

Other components include error logging and print utility, DEC Command Line 
(DCL) command interpreter. Monitor Console Routine (MCR) command interpreter, 
interactive and batch editors, macro assembler, linker with cross reference, 
library maintenance utility, Cjumon Run-Time Procedure Library, symbolic 
debugger for native programs, Record Management Services, FILES-11, SORT/MERGE 
utility. User Environment Test Package, and software maintenance release 
update utility. 

Although Ada is proposed as the primary language for all HTS development 
software, trained personnel and support compilers will not be available until 
late 1983 or early 1984. It is therefore suggested that FORTRAN-77 be used 
during early HTB development. VAX-11 FORTRAN is a full implementation of 
FORTRAN-77 and it is optimized to achieve high execution speed. A majority of 
the realtime simulation software for SAIL support is written in FORTRAN-77. 

5.7 SPECIAL HTS EQUIPMENT 

Any equipment that is not required in the normal operation of the HTS such as 
test equipment that costs more than lOK is considered to be special HTS 
equipment. 
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5.7.1 MICROPROCESSOR DEVELOPMENT SYSTEM 


At least three types of Intel microprocessors will be used in the development 
of the HTB. Whether these microprocessors are used as general purpose 
computers, post processors, or embedded processors, it will be necessary to 
nave a hardware and software microprocessor development system. There are 
numerous microprocessor development systems that are either dedicated or 

generalized, however, only one system is available for iAPX432 development. 
This system has a trade name Intel lec by Intel Corporation, the manufacturer 
of the iAPX432 microprocessor. The Intel lec can be configured as a 
development system for the following. 

• iAPX432 0 8088 e Intel Ethernet 0 286 

0 8086 0 8085 0 186 

It is planned that all may be used in the HTS. Additionally, the Intel 

model 311-VX Software Development Package contains a set of software 

development tools for the iAPX 86, 88, and (iAPX432 available mid '82). This 
package lets the user develop, edit, compile, and link and locate programs on 
a VAX 11/780 that have source-level and object-level compatibility with 
programs developed on an Intel lec Development System shown in figure 5-9. 

The Intel lec Development System environment can be used to debug an 
application created in the VAX 11/780 environment. Source and object modules 
may be downloaded to an Intel lec Development System (figure 5-10) via the 
Mainframe Link for Distributed Development (MDS-384) and debugged using the 
symbolic features of the In Circuit Emulator (ICE)-86 emulator. 

Source and object files created in an Intel lec system may be stored on the 

intellec system for quick access or uploaded to the VAX 11/780 for storage and 
control . 
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5.7.2 NETWORK MONITORS 


The ATB depends upon several network systems for distribution of data. A 
monitor or network analyzer will be necessary for development and maintenance 
of the Ethernet, MIL-STD-1553B and LACN (data link) networks. Coi ■ for these 
items is not available and each may require an in-house design such as the 
Data Systems Laboratory's Universal Bus Interface Controller (UBIC) system 
that has been used as an Orbiter data bus analyzer. 
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6. ATB MANAGEMENT SYSTEM 


The EAS and the HTS have been defined as separate, independently operated sys- 
tems with their development proceeding in parallel during the early phases of 
ATB development. The ATB Management System (AMS) requires both hardware and 
system engineering resources. An organization element discussed in section 7 
will be created specifically for the system management of the ATB. The goal 
of this organization will be to coordinate the design and configuration of the 
two systems for a major integrated facility. Additionally, the AMS function 
requires the design of a System Management Computer System. As presently 
conceived, this function will oe based in one VAX 11/780 operating in parallel 
with the HTS Data Management Function VAX 11/780 computer (reference fig- 
ures 6-1 and 3-1). The two mainframes will communicate via a 32 bit parallel 
high performance bus (DEC-DR780). This computer system also has access to the 
MIL-STD-1553B and Ethernet networks for system performance monitoring and data 
logging. The AMS function VAX 11/780 has its own private wideband video 
communications network (LACN). The LACN capabilities are shown in figure 6-1. 
This network is referred to as the System Management Network and it is used to 
control the subsystem manager's consoles located in each of the ATB functional 
areas. Additional AMS function features follow. 

6.1 SYSTEM MANAGERS CONSOLE 

The System Managers Console design allows complete reconfiguration by the 
utilization of flat screen touch sensitive television or plasma displays. All 
displays, labels, and control switches will be "soft". The same design con- 
cept will be used on the cockpit. Special CRTs for NAV AIDS will enhance 
reconfigurability. 

6.2 SCENE GENERATOR 

A TBD scene generator will provide high resolution scenes at the crew station 
while a CATV network (part of LACN) distributes scenes by compatible tele- 
vision to each of the subsystem managers consoles. Recent network designs 
have utilized CATV for voice, video, and broadband data communications on a 
single coaxial trunk. 
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Figure 6-1.- ATB Management System function computer system. 
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A large commercial market for CATV components makes this type of network 
economi cal . 

6.3 SYSTEM DATA BASE 

A major responsibility of the AMS function is to initialize tests, control 
tests via test procedures, and record results for post test data analysis. 
The system data base provides this function. 

All system test procedures are controlled by the system management console 
computer. This allows accurate repeatability of tests. This function is much 
more critical in a geographically distributed processing system. 
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7. MANAGEMENT AND BUSINESS PLAN 


In this section the existing organizational environment Is discussed as it 
relates to the development of the ATB. A concept of an appropriate management 
structure for the definition, development, and operation of the ATB Is pre- 
sented. Finally, recommendations are made for the Implementation of the man- 
agement scheme, and NASA and support contractor roles are discussed. 

7.1 ORGANIZATIONAL ENVIRONMENT 

The management structure for the ATB must be one that evolves from the 
existing system as the ATB concept Is further defined and funds are made 
available for Its Implementation. Recognition must be made of the large 
number of Inter- and Intra-organizational Interfaces which currently exist at.d 
will, by design, continue into the future. A major tenet of the AiB c'^-icept 
is that individual laboratories, simulation facilities, technical disciplines, 
etc. maintain their sovereignty and capability in functioning as independent 
entities. However, these entities must also be capable of functioning in an 
integrated fashion with each other as program requirements dictate. The need 
for cooperation and coordination between various organizations, both NASA and 
contractor, with potentially conflicting nriorities becomes a major concern in 
the development of the ATB. 

7.2 MANAGEMENT CONCEPTS 

Jn the following paragraphs, a proposed ATB management concept is developed 
which considers the issues presented above and identifies the organizational 
functions which must be addressed. No attempt will be made to specify in a 
detailed chart which functions will be addressed by an existing or future NASA 
or contractor organization. Rather, each function's responsibilities, inter- 
faces, and implementation will be covered. In order co avoid confusion with 
topics identified as functions elsewhere in this document, the organizational 
concepts or functions will be termed "Operations". 
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7.2.1 AVIONICS SYSTEMS ENGINEERING OPERATION 


In the present environment, the requirements for the analysis, evaluation, and 
testing of avionics software and hardware are generated by a number of diverse 
sources. Requirements are developed from existing NASA programs such as the 
Space Shuttle, from advanced technology application projects such as the 
electromechanical actuator and fiber optic data bus, and from anticipated 
needs of future programs such as the SOC. Each type of requirement Is handled 
individually in the various technology areas, and Interdisciplinary Issues are 
not routinely addressed unless there Is a specific program requirement. As 
spacecraft become larger and more complex with subsystems geographically 
distributed yet Interdependent, additional requirements for Interface 
Interaction and evaluation will be generated. These requirements will result 
In the need for the establishment of an Avionics Systems Engineering Operation 
(ASEO). This operation will address the Issues associated with total avionics 
development from an overall system viewpoint. It should define technology 
thrusts and plan the development activity required. One key responsibility 
will be to define avionics analysis, test, and evaluation requirements and to 
provide this information to the operations responsible for the ATB. This 
operation should be staffed with a core group systems engineering pro- 
fessionals supported by technical experts in the various disciplines. 

7.2.2 ATB PROJECT OPERATION 

Due to the large number of organizations which will be effected by the ATB 
concept and utilization, an ATB Project Operation (APO) should be established. 
The APO will be the top level management organization for the ATB. It will be 
responsible for coordinating system level avionics requirements with the ASEO, 
for the ATB design specifications, for math model configuration control and 
software transportability requirements, for the establishment of all formal 
interfaces, and for the overall management of the ATB. The APO will also be 
responsible for the direction of the ATB Management System (AMS) function des- 
cribed in paragraph 3.1.2. Supplemental tasks will include evaluating and 
establishing requirements for support elements or systems such as PERT for 
scheduling and CAUAM for automated design activities. In addition to its 
interfaces with the independent laboratories, functions, and technical areas, 
the APO will consist of at least two major sub-elements or operations: 
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7.2.2. 1 ATB Development Operations 


The ATB Develop’^nt Operation (ADO) will be responsible for the detail defini- 
tion and design of the ATB system. Fabrication or procurement of the .equired 
hardware and Its Installation, check-out, maintenance. Improvements, and rou- 
tine operation are the ADO's major assignments. This dedicated organization 
will establish and maintain appropriate Interfaces with other concerned areas 
to ensure all mutual and Independent objectives are met. 

7. 2. 2. 2 ATB Utilization Operation 

The ATB Utilization Operation (AUO) will be responsible for all tests and 
evaluations utilizing the ATB In an Integrated mode. It will be responsible 
for coordinating test requirements, procedures, schedules, and for the conduct 
of the test. Test configuration control, data management, and documentation 
are among the AUU's major activities. ATB user Interface Is also a prime 
responsibility of this dedicated organization. 

/.2.3 INDEPENDENT OPERATIONS 

The ATB concept allows for the continued individual operation and functioti of 
the various technology laboratories, simulation and analysis facilities, and 
engineering capabilities. However, these Independent operations will be 
required to establish, maintain, and operate appropriate interfaces with the 
ATB to provide an integrated capability. Close coordination and cooperation 
between the dedicated ATB operations and these independent areas must be a top 
level management requirement for the ATB to achieve Its full potential. 

7.3 SUMMARY AND IMPLEMENTATION 

The ATB will require the establishment of several new organizations and 
numerous new organizational relationships as depicted, in Figure 7-1. It is 
recommended that the ASEO and APO functions be established as soon as 
practical to initiate the required planning and organizational activities. 
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ATB MANAGEMENT CONCEPT 


Figure 7-1.- ATB management concept. 

These two operations should evolve from the existing organizations whenever 
possible, but will also require the addition of system engineering expertise. 
In this initial period the APO should develop ATB design requirements and 
establish working interfaces with the various independent operations. The 
independent operations in turn should assign specific responsibilities related 
to the ATB to personnel in their respectivo organizations. 

The ASEO is cwisioned as a NASA Office reporting at the Division level. The 
independent oi'erations will continue as NASA Brancn level operations, with 
contractor support. The NASA APO should initially be a NASA Office level 
organization with the potential to grow to the division level. The APO, AUO, 
and AUO functions are suitable for assignment to a support contractor. '' ese 
operations could easily evolve from the existing contractor support *’.o the 
various independent operations or laboratories. The most efficient met ;od in 
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the long term is considered to be the assignment of a mission type support 
contract to encompass the tasks associated with the ATB operations as well as 
those of the independent labs. 

Although a detailed management plan is beyond the scope of this document, the 
above concepts are provided for consideration and to provide a basis for 
further study. 
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8. CONCLUSIONS 


This document has defined a development plan for a practical and economical 
approach to implementing an Avionics Test Bed (ATB). The utilization of 
existing NASA ASD laboratory resources and commercial hardware and software 
systems makes the approach economical. An ATB man?!nement system (AMS) 
function was lescribed to coordinate the early parallel development of 
Engineering Analysis Simulatiyn (EAS) and Hardware Testing System (HTS) 
operations. This AMS function w'. il evolve into an ATB computer management 
system for an operational ATB. 

Several areas require additional study such as the computation requirements 
for the EAS, design requirements for the HTS SOC configuration, and the AMS 
design requirements. Specific design renuirements for each of the functional 
areas of the HTS will be prepared jy the AMS function as ATB tasks evolve. 

Aside frcm this document, this project also required a survey of the ASO com- 
puter and software resources that may be used for ATB development. Two docu- 
ments, (1) Hardware Survey for the Avionics Test Bed, LEMSCU-16838, JSC-17451, 
and (2) Software Survey for the Avionics Test Bed, LEMSCO-16941, JSC-17490, 
nave been completed and delivered. 

Finally, a memo was delivered to the NASA Oe.ta Systems Branch, EH4, with a 
cost estimate for materials and manpower tc implement the HTS and AMS segments 
of the ATB. This estimate identified several large equipment purchases (such 
as the VAX 11/730 computer) with long procurement lead times. These items 
should be procurred in FY82 to have an operational ATB by 1984. 

It is recommended additional tasks be initiated in FY82 to begin the 

implementation of the ...'B. These tasks include: 

1) EAS design requirements 

2) Design ’nd fabrication of HTS data bus terminals 

3) HTS development 

4) AMS design definition 
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